In "How to Write the Perfect Bug Report" Dan Loewenherz begins by telling a story:

You woke up this morning to a nice cup of coffee, opened up your application to get work done ... and you can't login.

First thing, DON'T PANIC. It's easy to feel helpless if you're not the developer, since you may think there's not much you can do.

Wrong! Your role is super important. You speak for the users. The better you do this, the quicker the issue will get fixed and the happier everyone will be. So if you find that you're stressed, just take a deep breath.

...

Brilliant advice, especially the reminder to remain calm, breathe, and "speak for the users" (an allusion to the movie Tron). It's also reminiscent of some of the best rules for bug reporting (and reporting almost anything else!) from the ancient (1980s) "Understanding Bug Reporting" guide in the GNU Emacs manual:

The most important principle in reporting a bug is to report facts. Hypotheses and verbal descriptions are no substitute for the detailed raw data. Reporting the facts is straightforward, but many people strain to posit explanations and report them instead of the facts. If the explanations are based on guesses about how Emacs is implemented, they will be useless; meanwhile, lacking the facts, we will have no real information about the bug. If you want to actually debug the problem, and report explanations that are more than guesses, that is useful—but please include the raw facts as well.

As in the TV detective show Dragnet: "All we want are the facts."

(cf. ParaMode (2000-05-09), PureTheory (2001-08-04), PickyAboutFacts (2003-03-11), ...) - ^z - 2013-09-24